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EURO PAYMENT ROUTING AND INTRA-DAY FLOW CONTROL 



SYSTEM AND METHOD 



FIELD OF THE INVENTION 

The present invention generally relates to systems and 
methods for the routing of payment transactions between financial 
institutions and more particularly to a system and method for routing and 
controlling the flow of Euro payments through a plurality of clearing 
channels. 

BACKGROUND OF THE INVENTION 

Effective January 1, 1999, the Euro was established as an 
official currency of many of the countries of the European Economic 
Union (EU). Currently, the members of the EU which have converted to 
the Euro are Germany, France, Spain, Belgium, Ireland, Italy, Luxembourg, 
The Netherlands, Austria, Portugal and Finland. The previous currencies 
of these countries will continue to be available for a transition period. 
They will be denominations of the Euro at fixed conversion rates. The 
Euro will have broad effects throughout Europe even though every 
European is not participating from the beginning. At the end of 2001 the 
previous currencies will cease to exist for electronic and account balance 
purposes. In the year 2002, the eleven European Union member states 
listed above will officially replace their previous currency notes and coins 
by Euro notes and coins. 

For each national currency (e.g., French Francs) the 
conversion rate to the Euro has been set and is fixed (will not fluctuate). 
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Foreign exchange operations in Euros have now begun. All new public 
debt issues in each of the EU countries will be in Euros and many 
outstanding ones will be re-denominated. National bank notes and coins 
will not yet be replaced, but banking is possible in both Euro and the 
5 national currency. 

By January 1, 2002, Euro notes and coins will gradually 
replace notes and coins in the national currencies. The national currencies 
must be withdrawn by July 1, 2002 at the latest. For companies outside of 
the financial sector, the main costs in converting to the Euro will be 

lft adapting information systems and, quite possibly reorganizing structures 

and procedures. The costs in the financial sector will be higher. Banks 
have had to be ready to operate in the Euro from January 1, 1999, in order 
to be able to handle payments by companies and individuals and to 

J cooperate with the European Central Bank, ECB, in the implementation of 

15 monetary policy. This has required banks to adapt their computer systems 

f to handle the new currency, to reorganize their operations in financial 
markets, to train staff and to develop new product and services for 
companies and individuals. 

While no one is compelled to use the Euro before January 1, 

20 2002, banks have had to prepare for the possibilities that some, many, or all 

of their customers might wish to do so. For those customers wanting Euro 
services before the year 2002, banks may offer Euro accounts. During the 
transitional period (January 1, 1999 through December 3 1, 2001), it would 
be possible for customers to keep their accounts in national currency and 

25 the banks will take care of receiving and making any Euro payments on 

these accounts at the fixed conversion rate. 

The Trans-European Automated Real-Time Gross settlement 
Express Transfer (TARGET) system is the electronic payment system 
which is a crucial instrument for the European Central Bank's conduct of 

3 o monetary policy. It is one mechanism which enables the cross boarder 
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transfer of funds between banks in real time and allows payments to be 
made through the Euro zone at low cost with high security and very short 
processing times, TARGET also helps the development of sound and 
efficient payment mechanisms in the single market. 

Together with the fifteen National Central Banks (NCBs) of 
the member countries, the ECB is part of the European System of Central 
Banks (ESCB) whose primary objective is maintaining price stability. The 
ESCB's basic tasks includes defining and implementing monetary policy 
for the Euro, conducting foreign exchange operation and holding and 
managing the official foreign reserves of the membered states. The ECB 
also promotes the smooth operation of payment systems and contributes to 
the work of the relevant national authorities and supervising credit 
institutions and stability of the financial system. 

Prior to the introduction to the Euro, there were 
approximately fourteen different systems for same day value clearing of 
payments in the 1 1 countries. Same day value clearing refers to the system 
and processes by which high value transactions are typically executed. 
With die introduction of the Euro, there are approximately nineteen same 
day clearing systems, but the clearing process now takes place in Euros, 
and not in any national currency. Furthermore, prior to the introduction of 
the Euro, clearing transactions in a particular currency were limited to same 
day clearing systems in that currency and these typically only exist in the 
country of the currency. For example, if two German banks were 
processing a payment between two customers in French Francs, the 
transaction had to have been cleared through the French clearing system. 
Now, this payment can be made through any of the 19 clearing systems as 
all of them are required to conduct transactions in Euros. 

The nineteen different clearing systems are constituted by 
fifteen Real Time Gross Settlement Systems (RTGS) and four non RTGS 
systems. 
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Figure 1 illustrates a clearing process prior to the introduction 
of the Euro. The example depicted in Figure 1 is a clearance between two 
German clearers 10, 15. As illustrated in this Figure, there were only two 
clearing systems EAF-2 20 and ELS 25 by which these two German 
clearers could process high value payments. 

Upon the introduction of the Euro, as depicted in Figure 2, a 
clearing between two Euro clearers 30, 35 can now take place through 
approximately 19 different same day clearing systems. These systems 
include the four non RTGS systems 40, and 15 RTGS systems 45. By 
using an RTGS 45 a Euro clearer 30, 35 can route a payment through the 
TARGET system 50 to reach a destination Euro clearer 30, 35. 
Furthermore, as illustrated in Figure 2, a Euro clearer 30, 35 can use a 
correspondent financial institution 55 to directly clear a payment or use the 
correspondent 55 to clear a payment through an RTGS or non RTGS 
system 60 to which the Euro clearer is not a member. A clearer 30, 35 will 
be a member of one or more of the RTGS or non RTGS systems. 

SUMMARY OF THE INVENTION 

The present invention is a system and method of routing Euro 
payments through one of the plurality of clearing channels. The method of 
the present invention is accomplished by two main processes, a routing 
process, and a flow control process. The routing process decides which 
clearing channel to use based on a number of factors such as the 
availability of the channel, customer instructions for routing, the clearing 
system memberships of the destination bank, agreements with the 
destination bank, priorities, and the type of payment. The flow control 
process monitors the balance for a clearing member within a selected 
channel, and the balance of the channel as a whole. Depending on whether 
the balances exceed predeteimined limits, the flow control process will 
either hold a routed payment or release it down the channel. The system 
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and method will allow customers to request specific Euro clearing 
mechanisms to be used for the Euro payment In the preferred 
embodiment, all clearing transactions for a financial institution will be 
processed by a central legal hub. This is likely to require cross border 
membership of clearing systems. The routing and flow control processes 
are executed at this central hub. In an alternative embodiment, the routing 
clearing system memberships/access can be accomplished on a branch by 
branch basis, but with central control monitoring die routing and flow 
control. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For the purposes of illustrating the present invention, there is 
shown in the drawings a form which is presently preferred, it being 
understood however, that the invention is not limited to the precise form 
shown by the drawing in which: 

Figure 1 illustrates a prior art method of clearing a payment; 

Figure 2 depicts the prior art channels of clearance after the 
introduction of the Euro; 

Figure 3 illustrates an overview of the system of the present 

invention. 

Figure 4 illustrates a preferred embodiment of the system of 
the present invention. 

Figure 5 is a flow chart of the preprocessing, routing and 
flow control processing at a hub location. 

Figure 6 shows the initial flow chart of the routing process. 

Figure 7 is a flow chart of the routing process when no route 
has been specified. 

Figure 8 depicts the decision process for selecting a channel 
where multiple are available. 
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Figure 9 is a table containing details of the members of the 

clearing systems. 

Figure 10 illustrates a table containing the details of all the 
channels through which me hub can directly or indirectly process a 
payment. 

DF.TATLED PFSrRIPTION OF THE INVENTION 

An overview of a preferred embodiment of the present 
invention is illustrated in Figure 3. Element 100 represents the global 
operations of a financial institution such as a bank. Elements 105-1 15 
represent the branches or subsidiaries of the bank distributed throughout 
the world. Element 120 represents a central legal entity, a hub, of the bank. 
In a preferred embodiment of the invention, hub 120 is a branch or 

subsidiary of the bank itself. 

Elements 125-150 represent six specific clearing channels to 
which the hub 120 is connected. Element 45 generically represents any 
RTGS clearing system while element 40 generically represents the MLNS 
systems. As in the prior art depicted in Figure 2, the hub 120 is also 
connected to correspondent financial institutions 55. Furthermore, each of 
the RTGSs 45, 125, 130 and 135 are illustrated as being connected to the 
TARGET system 50. As previously explained, through the TARGET 
system 50 any of the RTGSs are able to clear a payment through another 
RTGS. Other RTGS 45 and other non RTGS 40 clearing systems are 
important because they illustrate the flexibility of this invention. It is easy 
to add or drop clearing systems as appropriate with negligible impact on 
customers. This flexibility in using alternative channels is also very 
valuable in contingency situations. 

Operationally, all of the same day value payments to be 
cleared from the financial institution 100 are forwarded from the various 
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branches 105-1 15 to the central hub location 120. As the single hub 
location 120 receives all of the payments to be cleared, it has the ability to 
manage the clearance process for the entire financial institution 100. As 
will be more fully described below, this management function includes two 
primary components relating directly to the clearing channels, one for 
determining the routing of the payment through an appropriate channel, and 
one for controlling the flow of all of the financial institution's payments 
among all of the channels. Figure 4 schematically illustrates this payment 
routing and flow control portion 170 of the hub. Further illustrated in 
Figure 4 are the institutional and corporate customers 160 of the various 
branches 105-115 and hub branch 120. 

The method executed by the hub 120 in processing payments 
is illustrated in Figure 5. Step 200 in Fig. 5 processes incoming electronic 
messages (payment instructions) received by the hub 120. Such messages 
are transferred between the branches 105-1 15 and the hub 120 and between 
the institutional and corporate customers 160 and the hub 120. These 
messages can take many forms. Alternatively, payment instructions may be 
handled manually in which they are entered for processing via Manual 
Payment Input 215. With respect to payments, the transaction normally 
contains aU of the relevant information required to process the payment 
including at least an identification of the payor, the payee and the amount. 
Sometimes it is necessary to refer back to the transaction originator. 

When one of the customers of the hub 120 (e.g., branches 
105-115 or institutional or corporate customers 160) sends a payment 
instruction to the hub 120, the instruction may, but does not have to include 
routing instructions. For example, the customer of the hub might specify 
that the payment should be cleared through either RTGS or non RTGS 
without specifying the specific system to which routing can be made. 

The customer of the hub 120 can signify RTGS or non RTGS 
and additionally specify the specific RTGS non RTGS channel for use in 
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the routing. If a specific channel is identified, the hub 120 may or may not 
be a member of that specific channel. If the hub 120 is a member of that 
specific channel, the routing process described below will attempt to satisfy 
that specific request. If the hub 120 is not a member of the specific 
requested channel, the straight through processing 220 will set the payment 
type to CLG which indicates that the router is free to decide upon the route 
which the payment will take. Similarly, if the customer of the hub 120 
does not specify any routing preferences, the payment type will be set to 
CLG. 

The straight through processing 220 also ensures that 
sufficient details are contained in the payment instruction from the 
customer of the hub such mat once the transaction gets to the payment 
routing (described below) the router will have sufficient details to choose 
any of the available clearing channels without having to send the 
transaction for manual inspection and repair. The validation process in 
step 220 ensures that sufficient details are available to process the payment 
transaction through the preferred payment channel for the transaction. If 
the payment is for same day value, then any closed channels (past cut off) 
are ignored when determining the preferred channel. If the payment can be 
made through only one clearing system then step 220 will ensure mat 
sufficient details are present to process the payment transaction through 
that clearing system. If the payment can be made through many clearing 
systems, the straight through processing step 220 will ensure that sufficient 
details exist to process the payment transaction through only the preferred 

clearing system. 

Although the above has described the initial message 
processing 200 for messages sent from the branches 105-115 of the 
financial institution 100, similar rules apply if the payment instruction is 
coming directly from the institutional or corporate customers 160 of the 
hub 120 itself as depicted in Figure 4. This initial message and validation 



WO 00/36571 



PCT/GB99/04159 



-9- 

process 200 and the manual equivalent 215 are preferably also performed 
at each of the branches 105-115 as it receives payment instructions from its 

customers 160. 

Initial message processing 200 also processes incoming 
messages from the clearing systems which contain credits for customers 
160 of the financial institution 100 or for the financial institution 100 itself 
When a credit comes through a channel, the credit must be processed in 
order to update the relevant control balances described below. To do this, 
the credit message identifies the clearing channel from which the credit 
came and the bank which sent the payment into the clearing channel. For 
credits received cross-border via TARGET the bank who sent the payment 
into the clearing channel will be the National Central Bank for that 
channel. The flow control process of the present invention described 
below is not interested in the particular customer 160 of the financial 
institution 100 for which the credit is destined (or for itself), flow control is 
only interested in the fact that a credit came in from a particular clearing 
channel. This is because flow control is only interested in maintaining 
balances on all of the channels and pay-banks and in keeping track of when 
a particular channel or pay-bank reaches its limit. The further processing 
of credits do not form part of the present invention and are not discussed 
herein. 

In step 210, the initial message processing has identified 
outgoing payments received from customers of the hub 120. 

Payment instructions may be received via automated (steps 
200-210) or manual (step 215) means. Certain automated instructions may 
be of such a format that they are printed and processed as manual 
instructions. With transactions which are processed automatically, there 
are sophisticated processes to try to process these transactions without any 
manual intervention whatsoever. This is referred to as Straight Through 
Processing (STP) and the primary processing is in boxes 200, 210 and 220. 
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Where such a transaction cannot be processed straight through, it will go to 
payment repair 225 where an operator will amend the transaction such that 
it can continue processing. Only those details which are invalid or missing 
need be manually entered as all other details from the electronic processing 
are available. 

In extreme situations, it may be necessary to remove a 
transaction from the electronic processing and re-enter it as a manual 
instruction via Manual Payment Input 215. Manual Payment Input 215 
performs an equivalent role to initial message processing 200 and the two 
subsequent stages 210 and 212, but on manual transactions. Manual 
transactions may originate as manual instructions, or from automated 
instructions which are printed on receipt, or from automated instructions 
which are removed from Payment Repair 225, or from certain other 
exception situations. 

Transactions entered via manual payment input 215 are 
subject to Verification 230 of critical data by a second operator. Similarly, 
transactions going though payment repair 225 are also subject to 
Verification 230. If an error is identified at Verification 230, the 
transaction is returned to an earlier stage for correction. 

Under certain conditions, automated instructions may be sent 
direct from Straight Through Processing 220 to Verification 230. In rare 
instances, transactions at subsequent stages may be returned to Payment 
Repair 225. 

After Straight Through Processing 220 or verification 230, 
transactions are fully validated. In Forward Value 235, transactions may 
be held in a queue awaiting value date. When the value date occurs, the 
transactions are released from the forward queue. Transactions are subject 
to Risk Control 245 which ensures that the outgoing payments for a 
particular customer do not exceed the receipts by more than a defined limit. 
It is desirable to do this process as late as possible to keep the limits to the 
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Tninimnni Full automation of all subsequent stages of processing, e.g. in 
payment routing and flow control, is essential to minimize the limits, and 
therefore the risk which is taken by the financial institution. 

On entering the Router 250, a brief variable delay period is 
applied in case the last manual operation proved to be incorrect This 
allows the operator to retrieve this transaction. Once this delay period has 
expired, the transaction becomes irrevocable, unless identified as an 
exception at one of the subsequent automated states. On becoming 
irrevocable, the transaction status is updated to (transaction) inactive. 

Element 250 is the Payment Router of the present invention. 
Payment router 250 shall be discussed below in more detail, but in general 
the Payment Router 250 decides, based on a series of rules, how a payment 
should be routed through the various channels 280. Channels 280 
genetically describe the various RTGS and non RTGS channels previously 
described. Once the appropriate channel for transmission of the payment 
has been determined by Payment Router 250, the Payment Router 250 
passes the payment transaction onto the flow control processes 255. 

The first flow control method, bi-lateral limit validation 260, 
checks the proposed payment against the balance currently maintained by 
the hub 120 for the clearing member (the destination pay-bank on an 
individual channel basis). This will only apply where the transaction is 
being routed down a channel to which both the hub 120 and the destination 
pay bank are directly connected. All cross border transactions via 
TARGET will be accumulated against the National Central Bank which 

operates the system. 

The flow control processing monitors the bi-lateral limits 
within the clearing systems. It maintains the total number and amounts of 
payment set to each destination clearer on a daily basis. If a proposed 
payment would put the totals over the limit which has been set for that 
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destination clearer, then the flow control process puts a hold on the 
payment and will not let it be transferred out of the hub 120. 

A second process 262 performed in the Flow Control module 
255 looks at the ma ^"""" amount for an individual payment through each 
channel 280. Transactions which are above this maximum level require 
manual action. 

The third process 265 performed in the flow control method 
255 looks at the balance for the selected channel as a whole. In steps 260- 
265, it is determined whether or not the proposed payment transaction 
exceeds set limits. If the proposed payment would exceed one of these 
predetermined limits in any of theses steps 260-265, the determination of 
the fate of the proposed payment may be determined in an on-line flow 
control process 270. Alternatively there are automated re-try processes 
within the bi-lateral 260 and overall checks 265 which are invoked 
periodically during the day to take into account each new credit received 
for the relevant channel 280. 

In the on-line flow control process 270, an operator manually 
reviews the transaction and the current circumstances which caused the 
transaction to exceed the redetermined limits. The operator may have 
additional knowledge by which he or she may determine that a payment 
may be passed on to a particular channel even though its clearing will 
exceed the predetermined limits. For example, the operator might have 
knowledge that a particular credit has not yet been posted to the channel 
balance and that the processing of the proposed payment transaction will 
not be denied by the channel because of excess debits. At this stage, in 
rare instances, the operator may need to return the payment to Payment 
Repair 225. 

The on-line flow control function 270 also provides for 
inquiring on and controlling payments held at the various stages of the flow 
control checks 260, 265. The on-line flow control process 270 is manually 
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operated by the operators at the hub 120. Using this on-line system 270 the 
operators are able to select one or more of the clearing queues in order to 
display all of the held payments. Additionally, the operators can manually 
release any of the queued payments down the specified channel 280 if 
required. Furthermore, the operators can manually put a payment back into 
the Payment Router 250 so a different channel 280 can be selected. Re- 
routing back to the Routing module 250 or releasing of a payment from the 
hold queue will cause the bi-lateral and channel totals to be automatically 
updated as appropriate. 

The flow control limits for each of the channels and the 
clearing member banks are stored in a table. These limits are keyed both 
with respect to the clearing member bank to which payment instructions are 
sent, and by the clearing channel The table contains the agreed upon 
balance limits, the current balance, the number of payments held due to the 
limit checks, and the maximum value of individual payments allowed. 
These limits can be manually updated in a rapid fashion if a contingency 

situation arises. 

A function exists which allows the manual adjustment of the 
flow control balance for a clearing channel. This is important to take into 
account any non-clearing related movements across the external clearing 
accounts, for example liquidity movements or start of day RTGS balances. 

The flow control processing has a number of generic defaults 
which apply in new situations where limits have not previously been set by 
the operators. For example where a new bank joins a clearing, if an 
operator has not previously defined a limit for that bank then some default 
processing will apply to control payments for that bank with a limit forcing 
all payments to be held. 

Once the proposed payment has passed the flow control 
processing 255, it is passed on to the Product Generation module 275. In 
Product Generation 275, the actual message which is transmitted to the 
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channels 280 for clearing is generated. The format of the messages which 
are generated, will differ depending on which channel 280 is used. Upon 
reaching a defined stage of processing, the channel 280 will return an 
acknowledgment 285 which is used to update the hub's 120 records as 
appropriate. Other products may be generated in Product Generation 275 
such as advices to various parties to the transaction. 

A contingency function is provided to capture payments that 
have either been rejected at the clearing bank or encountered in an error at 
some stage of the payment flow out to the clearing bank. If such is the 
case, the rejected or errored payments can be manually set back to payment 
repair (step 225) or back to the Payment Router 250 (see step 300 in Fig. 
6)- 

Figures 6-8 illustrate the processing of the Payment Router 
250 of the presentinvention. The processing starts at step 300 with an 
initialization process 305 in which technical preparatory work is 
performed. 

In step 3 10, the record for the proposed transaction is read. 
As previously described, the message from the customers of the hub 120 
will contain at least an identification of the payor, payee and the amount of 
the payment. Additionally, the transaction record may contain an 
identification of a clearing channel which is preferred by the customer 160. 
If the customer does not identify a preferred channel of clearance, this field 
will contain the payment type CLG. In step 325, it is determined whether 
or not a clearing channel has yet been identified. As previously described, 
this channel can be identified by the customer, or alternatively can be 
manually entered by the operators of the hub 120. If the payment type is 
set to CLG, the router is free to automatically determine the appropriate 
channel for routing as illustrated in Figures 7 and 8, During this 
subsequent routing decision process, the payment type will change to EAF, 
EBA, etc, once the appropriate route has been decided. 
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If the routing has already been determined (payment type is 
not CLG), the process moves to step 330. Examples of payments for which 
routing has already been decided (i.e., the specific channel has been 
defined) are: liquidity payments; payments for which the customer 160 has 
specified the exact clearing channel to be used; or payments for which the 
operators of the hub have manually input the channel. Although these 
types of payments do not require a decision making process for the type of 
channel to be used, these payments will still be forwarded to the flow 
control process before the payment is actually released to the channel. Step 
330 initiates the process of deciding if the specified channel is available. 

In step 335, it is determined whether or not the channel is 
available for use at all. In the preferred embodiment of the present 
invention, a channel table is maintained which contains the status of all of 
the channels to which the hub 120 is connected. An example of such a 
clearing channel table is in contained in Figure 10. If the channel is not 
available as determined by the status field contained in the clearing channel 
table, the process continues at step 365 described below. If the channel is 
available, it is then decided at step 340 whether or not the particular 
channel is on holiday. As some of the institutions which maintain the 
channels recognize national holidays which are not universal, a channel 
could be on a different holiday schedule than observed by the hub 120. 
The holiday schedule for each channel is maintained in the clearing 
channel table (Fig. 10). If the channel is on holiday, the processing will 
continue in step 365. If the channel is not on holiday, it is determined 
whether or not the cut off time for the channel has been reached for the 
type of payment (for some channels different cut off times apply for MtlOO 
and Mt202 payments). The cut-off time is the last time of day at which a 
channel will except a payment for processing. The cut-off time details are 
contained in the channel table illustrated in Figure 10. If the cut-off time 
has already passed, processing continues in step 365. If there is sufficient 
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time to pass die payment on to the channel, the process continues in step 
350. Step 350 has been included in this Figure to indicate that additional 
checks may be made with respect to the channel availability such as the 
current debit position. 

If the channel availability tests 335-350 are all satisfied, it is 
determined in step 355 if there are any other special formatting 
requirements. The payment transaction is sent to the flow control 
processing in step 360 (see step 255 in Fig. 5). 

If the processing has reached step 365, it is because the 
requested or designated channel is not available for use. In step 365 it is 
determined whether or not the payment is a liquidity payment Le., a 
payment initiated by the hub 120 solely for the purposes of moving funds 
from one channel to another - moving the liquidity. 

If the payment is a liquidity payment, the channel can not be 
changed because of the nature of die payment as described above (step 
370). If such is the case, the payment is sent back to payment repair in step 
375 (see Fig. 5). 

If the payment whose channel is unavailable is not a liquidity 
payment (NO out of step 365) it is determined whether or not there is any 
information contained in the payment transaction record which identifies 
the type of channel which should be used (e.g., use RTGS, but the specific 
RTGS channel is not identified). If such information does exist in the 
payment transaction record, the channel type is set to the appropriate type 
(e.g., RTGS)(step 390). Note that /NETT/ is a generic coding used in the 
system to identify a request for a non RTGS clearing channel, while 
/RTGS/ identifies a request for an RTGS channel. If no such channel 
details exists in the transaction record, the channel type is set depending on 
the payment type of the instruction. The payment type will indicate the 
channel which was originally chosen. If this is of type RTGS, channel type 
will be set to /RTGS/. If it is of non RTGS type, channel type will be set to 
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7NETT/. The channel type is retrieved from the channel table contained in 
Figure 10. 

Once the channel type has been set, the payment type is set to 
CLG (step 395) and the payment transaction is sent on to the process for 
determining the particular channel as illustrated in Figure 7. 

Step 400 in Figure 7 is the initiation of the routing process 
when no specific route has been identified (step 327 in Fig. 6) or when the 
request for a specified channel could not be satisfied (step 397 in Fig. 6). 
hi step 405 a list of available clearing channels is retrieved using the 
clearing channel tables depicted in Figures 9 and 10. If the transaction 
specifies that the payment should be processed through an RTGS or a non 
RTGS channel, any non-RTGS or RTGS clearing channels respectively 
should be excluded from this list 

In step 410 it is determined whether or not a destination 
clearing bank is directly connected to any of the same clearing systems as 
the hub 120. If clearing channel returned is TGT (TARGET) or COR 
(correspondent), there is no such mutual direct connection. 

If in step 410 it is determined that there is a mutual direct 
connection, in step 415 it is determined whether there is more than one. 
This determination is made using the clearing channel options determined 
in 405. The CMD table depicted in Figure 9 allows for the maintenance of 
channel membership by pay- bank. Each pay-bank/channel combination is 
held in a different record in the table. This structure allows for easier 
prioritizing of channels when a pay-bank is a member of more than one 
clearing system. The pay-bank/ channel information can either be 
manually maintained or an electronic batch process may capture the 
channel membership details. In order to limit the complexity of the router 
and other parts of the system, and to have a common interface to the pay- 
bank/channel details, it is preferred that all channel member details are 
contained in a single table and each of the channel details conform to the 
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same standard record format. This means for example that German 
clearing information, which normally identifies banks with a local German 
BLZ code is not used. Instead, the universal Society for World-Wide Inter- 
bank Financial Telecommunications (SWIFT) code is used to identify 
banks. As illustrated in Figure 9, the CMD table also contains details 
relating to the preferred routing method. If a pay-bank and the hub 120 
have more than one mutual direct connection, the priority is indicated in 
the CMD table but only if this differs from the default priority as held on 
the ECC table illustrated in Figure 10. If the pay-bank and the hub 120 do 
not have a mutual direct connection, TGT (TARGET) and/or COR 
(correspondent) may be loaded on the ECC table with priority set where 
necessary. 

Returning to Figure 7, if the pay-bank is not a member of 
more than one clearing system (step 415) a validation is performed in order 
to verify that that channel can be used (step 420). As previously described 
with respect to steps 335-350 in Figure 6, such validation can include 
determining if the channel is on holiday or if the cut-off time for that 
channel has been reached. Again, this validation process employs the 
clearing channel table as depicted in Figure 10. If it is determined that the 
channel cannot be used (NO out of step 425) the proposed transaction is 
sent to repair for manual determination of how to process the transaction as 
previously described. If the channel can be used, the payment type in the 
transaction record is set to the specified channel in step 435. 

Returning to the NO path out of step 410, this path is 
followed if either the TARGET system or a correspondent is to be used as 
the clearing channel. In step 440, it is determined whether it is the 
TARGET system or a correspondent which is to be used. If a 
correspondent is to be used, the payment type is set to CPO and the 
correspondent details are read from the clearing channel table (Fig. 10). In 
step 445, the record for the correspondent in the clearing channel table is 
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read which contains the SWIFT addressed for the correspondent which will 
enable routing of the payment transaction. 

In step 450, the process determines if there are any specific 
formatting requirements for the channel which has been specified by the 
routing process, and the payment transaction is forwarded to the flow 
control process in step 455 (see Fig. 5). 

If it is determined in step 440 that the TARGET system is to 
be used, the list of available clearing channels obtained in step 405 is 
narrowed to only included the RTGS clearings. This narrowed list is then 
prioritized according to default priorities. Similarly, in step 465, if a pay- 
bank is a member of more than one clearing system (YES out of step 415) 
the available clearing systems to which the pay-bank is a member are 
prioritized. However, in the instance the pay-bank override priority from 
the CMD table (Figure 9) will be used if it is present. In either of these 
cases, the list of available prioritized channels is passed to the process (Fig. 
8) for deciding the channel which is to be used to transfer the funds in step 
470. 

Information on priority of payment channel is maintained 
manually. A default priority will be entered on the ECC table (Figure 10). 
If an override priority is to apply for a pay-bank this is entered on the CMD 
table (Figure 9). 

In step 500 of Figure 8, the prioritized list of channels which 
can be used to route the payment is provided to the channel decision 
process. In step 505, the priority will be changed if required by 
circumstances at the time the final decision is being made. For example, 
certain payment channels require a minimum volume of payments to be 
submitted as held on the ECC table (Figure 10). These "priority changes" 
are automated. 

In step 510, it is determined whether all of the channels in the 
list have been processed. If not, a decision making process is performed in 
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steps 5 15-530. The decision making process 515-530 is the same as 
discussed above with respect to step 420 in Figure 7 and steps 335-350 in 
Figure 6. If a channel passes all the rules and can therefore be used, the 
payment type is set to the specified channel and any special formatting 
required for that channel is identified in step 535. The payment transaction 
is then sent to the flow control process in step 540. 

If all of the available channels have been processed and none 
of them, for one reason or another, is available for use (YES out of step 
5 10) an error is generated as no channel can be used (step 545). If such is 
the case, the payment transaction is sent to repair for manual determination 
of the appropriate channel to use in routing the transaction (step 550). 

Supporting this invention there are a number of generic 
"housekeeping" processes which will run on periodic bases to ensure the 
smooth operation.- These are not defined specifically, but include a nightly 
reset of Flow Control balances to zero and a cleardown of historical data 
from the Flow Control Process. 

Although the present invention has been described in relation 
to particular embodiments thereof, many other variations and other uses 
will be apparent to those skilled in the art. It is preferred, therefore, that 
the present invention be limited not by the specific disclosure herein, but 
only by the gist and scope of the disclosure. 



